home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc993.txt < prev    next >
Text File  |  1994-08-01  |  70KB  |  1,652 lines
  1.  
  2.  
  3. Network Working Group                              David D. Clark (MIT)
  4. Request for Comments: 993                         Mark L. Lambert (MIT)
  5. Obsoletes:  RFC-984                                       December 1986
  6.  
  7.  
  8.  
  9.         PCMAIL: A Distributed Mail System for Personal Computers
  10.  
  11.  
  12.  
  13. 1. Status of this Document
  14.  
  15.    This document is a discussion of the Pcmail workstation-based distri-
  16.    buted mail system.  It is a revision of the design published in NIC
  17.    RFC-984.  The revision is based on discussion and comment from a
  18.    variety of sources, as well as further research into the design of
  19.    interactive Pcmail clients and the use of client code on machines
  20.    other than IBM PCs.  As this design may change, implementation of
  21.    this document is not advised.  Distribution of this memo is unlimit-
  22.    ed.
  23.  
  24. 2. Introduction
  25.  
  26.    Pcmail is a distributed mail system providing mail service to an ar-
  27.    bitrary number of users, each of whom owns one or more workstations.
  28.    Pcmail's motivation is to provide very flexible mail service to a
  29.    wide variety of different workstations, ranging in power from small,
  30.    resource-limited machines like IBM PCs to resource-rich (where
  31.    "resources" are primarily processor speed and disk space) machines
  32.    like Suns or Microvaxes.  It attempts to provide limited service to
  33.    resource-limited workstations while still providing full service to
  34.    resource-rich machines.  It is intended to work well with machines
  35.    only infrequently connected to a network as well as machines per-
  36.    manently connected to a network.  It is also designed to offer disk-
  37.    less workstations full mail service.
  38.  
  39.    The system is divided into two halves.  The first consists of a sin-
  40.    gle entity called the "repository".  The repository is a storage
  41.    center for incoming mail.  Mail for a Pcmail user can arrive exter-
  42.    nally from the Internet or internally from other repository users.
  43.    The repository also maintains a stable copy of each user's mail state
  44.    (this will hereafter be referred to as the user's "global mail
  45.    state").  The repository is therefore typically a computer with a
  46.    large amount of disk storage.
  47.  
  48.    The second half of Pcmail consists of one or more "clients".  Each
  49.    Pcmail user may have an arbitrary number of clients, typically
  50.    single-user workstations.  The clients provide a user with a friendly
  51.    means of accessing the user's global mail state over a network.  In
  52.    order to make the interaction between the repository and a user's
  53.    clients more efficient, each client maintains a local copy of its
  54.  
  55.  
  56.  
  57. Clark & Lambert                                                 [Page 1]
  58.  
  59. RFC 993                                                    December 1986
  60.  
  61.  
  62.    user's global mail state, called the "local mail state".  It is as-
  63.    sumed that clients, possibly being small personal computers, may not
  64.    always have access to a network (and therefore to the global mail
  65.    state in the repository).  This means that the local and global mail
  66.    states may not be identical all the time, making synchronization
  67.    between local and global mail states necessary.
  68.  
  69.    Clients communicate with the repository via the Distributed Mail Sys-
  70.    tem Protocol (DMSP); the specification for this protocol appears in
  71.    appendix A. The repository is therefore a DMSP server in addition to
  72.    a mail end-site and storage facility.  DMSP provides a complete set
  73.    of mail manipulation operations ("send a message", "delete a mes-
  74.    sage", "print a message", etc.).  DMSP also provides special opera-
  75.    tions to allow easy synchronization between a user's global mail
  76.    state and his clients' local mail states.  Particular attention has
  77.    been paid to the way in which DMSP operations act on a user's mail
  78.    state.  All DMSP operations are failure-atomic (that is, they are
  79.    guaranteed either to succeed completely, or leave the user's mail
  80.    state unchanged ).  A client can be abruptly disconnected from the
  81.    repository without leaving inconsistent or damaged mail states.
  82.  
  83.    Pcmail's design has been directed by the characteristics of currently
  84.    available workstations.  Some workstations are fairly portable, and
  85.    can be packed up and moved in the back seat of an automobile.  A few
  86.    are truly portable--about the size of a briefcase--and battery-
  87.    powered.  Some workstations have constant access to a high-speed
  88.    local-area network; pcmail should allow for "on-line" mail delivery
  89.    for these machines while at the same time providing "batch" mail
  90.    delivery for other workstations that are not always connected to a
  91.    network.  Portable and semi-portable workstations tend to be
  92.    resource-poor.  A typical IBM PC has a small amount (typically less
  93.    than one megabyte) of main memory and little in the way of mass
  94.    storage (floppy-disk drives that can access perhaps 360 kilobytes of
  95.    data).  Pcmail must be able to provide machines like this with ade-
  96.    quate mail service without hampering its performance on more
  97.    resource-rich workstations. Finally, all workstations have some com-
  98.    mon characteristics that Pcmail should take advantage of.  For in-
  99.    stance, workstations are fairly inexpensive compared to the various
  100.    time-shared systems that most people use for mail service.  This
  101.    means that people may own more than one workstation, perhaps putting
  102.    a Microvax in an office and an IBM PC at home.
  103.  
  104.    Pcmail's design reflects the differing characteristics of the various
  105.    workstations.  Since one person can own several workstations, Pcmail
  106.    allows users multiple access points to their mail state.  Each Pcmail
  107.    user can have several client workstations, each of which can access
  108.    the user's mail by communicating with the repository over a network.
  109.    The clients all maintain local copies of the user's global mail
  110.    state, and synchronize the local and global states using DMSP.
  111.  
  112.    It is also possible that some workstations will only infrequently be
  113.  
  114.  
  115.  
  116. Clark & Lambert                                                 [Page 2]
  117.  
  118. RFC 993                                                    December 1986
  119.  
  120.  
  121.    connected to a network (and thus be able to communicate with the re-
  122.    pository).  The Pcmail design therefore allows two modes of communi-
  123.    cation between repository and client.  "Interactive mode" is used
  124.    when the client is always connected to the network.  Any changes to
  125.    the client's local mail state are immediately also made to the
  126.    repository's global mail state, and any incoming mail is immediately
  127.    transmitted from repository to client.  "Batch mode" is used by
  128.    clients that have infrequent access to the repository.  Users manipu-
  129.    late the client's local mail state, queueing the changes locally.
  130.    When the client is next connected to the repository, the changes are
  131.    executed, and the client's local mail state is synchronized with the
  132.    repository's global mail state.
  133.  
  134.    Finally, the Pcmail design minimizes the effect of using a resource-
  135.    poor workstation as a client.  Mail messages are split into two
  136.    parts: a "descriptor" and a "body".  The descriptor is a capsule mes-
  137.    sage summary whose length (typically about 100 bytes) is independent
  138.    of the actual message length.  The body is the actual message text,
  139.    including an RFC-822 standard message header.  While the client may
  140.    not have enough storage to hold a complete set of messages, it can
  141.    usually hold a complete set of descriptors, thus providing the user
  142.    with at least a summary of his mail state.  For clients with extreme-
  143.    ly limited resources, Pcmail allows the storage of partial sets of
  144.    descriptors.  Although this means the user does not have a complete
  145.    local mail state, he can at least look at summaries of some messages.
  146.    In the cases where the client cannot immediately store message bo-
  147.    dies, it can always pull them over from the repository as storage be-
  148.    comes available.
  149.  
  150.    The remainder of this document is broken up into sections discussing
  151.    the following:
  152.  
  153.       - The repository architecture
  154.  
  155.       - DMSP, its operations, and motivation for its design
  156.  
  157.       - The client architecture
  158.  
  159.       - A typical DMSP session between the repository and a
  160.         client
  161.  
  162.       - The current Pcmail implementation
  163.  
  164. 3. Repository architecture
  165.  
  166.    A typical machine running repository code has a relatively powerful
  167.    processor and a large amount of disk storage.  It must also be a per-
  168.    manent network site, for two reasons.  First clients communicate with
  169.    the repository over a network, and rely on the repository's being
  170.    available at any time.  Second, people sending mail to repository
  171.    users rely on the repository's being available to receive mail at any
  172.  
  173.  
  174.  
  175. Clark & Lambert                                                 [Page 3]
  176.  
  177. RFC 993                                                    December 1986
  178.  
  179.  
  180.    time.
  181.  
  182.    The repository must perform several tasks.  First, and most impor-
  183.    tantly, the repository must efficiently manage a potentially large
  184.    number of users and their mail states.  Mail must be reliably stored
  185.    in a manner that makes it easy for multiple clients to access the
  186.    global mail state and synchronize their local mail states with the
  187.    global state.  Since a large category of electronic mail is
  188.    represented by bulletin boards (bboards), the repository should effi-
  189.    ciently manage bboard mail, using a minimum of storage to store
  190.    bboard messages in a manner that still allows any user subscribing to
  191.    the bboard to read the mail.  Second, the repository must be able to
  192.    communicate efficiently with its clients.  The protocol used to com-
  193.    municate between repository and client must be reliable and must pro-
  194.    vide operations that (1) allow typical mail manipulation, and (2)
  195.    support Pcmail's distributed nature by allowing efficient synchroni-
  196.    zation between local and global mail states.  Third, the repository
  197.    must be able to process mail from sources outside the repository's
  198.    own user community (a primary outside source is the Internet).  In-
  199.    ternet mail will arrive with a NIC RFC-822 standard message header;
  200.    the recipient names in the message must be properly translated from
  201.    the RFC-822 namespace into the repository's namespace.
  202.  
  203. 3.1. Management of user mail state
  204.  
  205.    Pcmail divides the world into a community of users.  Each user is re-
  206.    ferred to by a user object.  A user object consists of a unique name,
  207.    a password (which the user's clients use to authenticate themselves
  208.    to the repository before manipulating a global mail state), a list of
  209.    "client objects" describing those clients belonging to the user, and
  210.    a list of "mailbox objects".
  211.  
  212.    A client object consists of a unique name and a status.  A user has
  213.    one client object for every client he owns; a client cannot communi-
  214.    cate with the repository unless it has a corresponding client object
  215.    in a user's client list.  Client objects therefore serve as a means
  216.    of identifying valid clients to the repository.  Client objects also
  217.    allow the repository to manage local and global mail state synchroni-
  218.    zation; the repository associates with every global state change a
  219.    list of client objects corresponding to those clients which have not
  220.    recorded the global change locally.
  221.  
  222.    A client's status is either "active" or "inactive".  The repository
  223.    defines inactive clients as those clients which have not connected to
  224.    the repository within a set time period (one week in the current re-
  225.    pository implementation).  When an inactive client does connect to
  226.    the repository, the repository notifies the client that it has been
  227.    "reset".  The repository resets a client by marking all messages in
  228.    the user's mail state as having changed since the client last logged
  229.    in.  When the client next synchronizes with the repository, it will
  230.    receive a complete copy of the repository's global mail state.  A
  231.  
  232.  
  233.  
  234. Clark & Lambert                                                 [Page 4]
  235.  
  236. RFC 993                                                    December 1986
  237.  
  238.  
  239.    forced reset is performed on the assumption that enough global state
  240.    changes occur in a week that the client would spend too much time
  241.    performing an ordinary local state-global state synchronization.
  242.  
  243.    Messages are stored in mailboxes.  Users can have an arbitrary number
  244.    of mailboxes, which serve both to store and to categorize messages.
  245.    A mailbox object both names a mailbox and describes its contents.
  246.    Mailboxes are identified by a unique name; their contents are
  247.    described by three numeric values.  The first is the total number of
  248.    messages in the mailbox, the second is the total number of unseen
  249.    messages (messages that have never been seen by the user via any
  250.    client) in the mailbox, and the third is the mailbox's next available
  251.    message unique identifier (UID).  The above information is stored in
  252.    the mailbox object to allow clients to get a summary of a mailbox's
  253.    contents without having to read all the messages within the mailbox.
  254.  
  255.    Some mailboxes are special, in that other users may read the messages
  256.    stored in them.  These mailboxes are called "bulletin board mail-
  257.    boxes" or "bboard mailboxes".  The repository uses bboard mailboxes
  258.    to store bboard mail.  Bboard mailboxes differ from ordinary mail-
  259.    boxes in the following ways:
  260.  
  261.       - Their names are unique across the entire repository;
  262.         for instance, only one bboard mailbox named "sf-lovers"
  263.         may exist in the entire repository community.  This
  264.         does not preclude other users from having an ordinary
  265.         mailbox named "sf-lovers".
  266.  
  267.       - Subscribers to the bboard are granted read-only access
  268.         to the messages in the bboard mailbox.  The bboard
  269.         mailbox's owner (typically the system manager) has
  270.         read/update/delete access to the mailbox.
  271.  
  272.    A bboard subscriber keeps track of the messages he has looked at via
  273.    a bboard object.  The bboard object contains the name of the bboard,
  274.    its owner (the user who owns the bboard mailbox where all the mes-
  275.    sages are stored), and the UID of the first message not yet seen by
  276.    the subscriber .
  277.  
  278.    Users gain read-only access to a bboard by "subscribing" to it; they
  279.    lose that access when they "unsubscribe" to it.
  280.  
  281.    Associated with each mailbox are an arbitrary number of message ob-
  282.    jects.  Each message is broken into two parts--a "descriptor", which
  283.    contains a summary of useful information about the message, and a
  284.    "body", which is the message text itself, including its NIC RFC-822
  285.    message header.  Each message is assigned a monotonically increasing
  286.    UID based on the owning mailbox's next available UID.  Each mailbox
  287.    has its own set of UIDs which, together with the mailbox name and
  288.    user name, uniquely identify the message within the repository.
  289.  
  290.  
  291.  
  292.  
  293. Clark & Lambert                                                 [Page 5]
  294.  
  295. RFC 993                                                    December 1986
  296.  
  297.  
  298.    A descriptor holds the following information: the message UID, the
  299.    message size in bytes and lines, four "useful" message header fields
  300.    (the "date:", "to:", "from:", and "subject:" fields), and sixteen
  301.    flags.  These flags are given identifying numbers 0 through: 15.
  302.    Eight of these flags are reserved for the repository's use.  Some of
  303.    these are actually used by the repository, while others are simply
  304.    held for informational purposes.  In the current repository implemen-
  305.    tation these flags mark:
  306.  
  307.       - (#0) whether it has been deleted
  308.  
  309.       - (#1) whether the message has been seen
  310.  
  311.       - (#2) whether it has been forwarded to the user
  312.  
  313.       - (#3) whether it has been forwarded by the user
  314.  
  315.       - (#4) whether it has been filed (written to a text file
  316.         outside the repository)
  317.  
  318.       - (#5) whether it has been printed (locally or remotely)
  319.  
  320.       - (#6) whether it has been replied to
  321.  
  322.       - (#7) whether it has been copied to another mailbox
  323.  
  324.    The remaining eight flags are reserved for future use.
  325.  
  326.    Descriptors serve as an efficient means for clients to get message
  327.    information without having to waste time retrieving the message from
  328.    the repository.
  329.  
  330. 3.2. Repository-to-RFC-822 name translation
  331.  
  332.    "Address objects" provide the repository with a means for translating
  333.    the RFC-822-style mail addresses in Internet messages into repository
  334.    names.  The repository provides its own namespace for message iden-
  335.    tification.  Any message is uniquely identified by the triple (user-
  336.    name, mailbox-name, message-UID).  Any mailbox is uniquely identified
  337.    by the pair (user-name, mailbox-name).  Thus to send a message
  338.    between two repository users, a user would address the message to
  339.    (user-name, mailbox-name).  The repository would deliver the message
  340.    to the named user and mailbox, and assign it a UID based on the re-
  341.    quested mailbox's next available UID.
  342.  
  343.    In order to translate between RFC-822-style mail addresses and repo-
  344.    sitory names, the repository maintains a list of address objects.
  345.    Each address object is an association between an RFC-822-style ad-
  346.    dress and a (user-name, mailbox-name) pair.  When mail arrives from
  347.    the Internet, the repository can use the address object list to
  348.    translate the recipients into (user-name, mailbox-name) pairs and
  349.  
  350.  
  351.  
  352. Clark & Lambert                                                 [Page 6]
  353.  
  354. RFC 993                                                    December 1986
  355.  
  356.  
  357.    route the message correctly.
  358.  
  359. 4. Communication between repository and client: DMSP
  360.  
  361.    The Distributed Mail System Protocol (DMSP) is a block-stream proto-
  362.    col that defines and manipulates the objects mentioned in the previ-
  363.    ous section.  It has been designed to work with Pcmail's single-
  364.    repository/multiple-client model of the world.  In addition to pro-
  365.    viding typical mail manipulation functions, DMSP provides functions
  366.    that allow easy synchronization of global and local mail states.
  367.  
  368.    DMSP is implemented on top of the Unified Stream Protocol (USP),
  369.    specified in MIT-LCS RFC-272.  USP provides a reliable virtual cir-
  370.    cuit block-stream connection between two machines.  It defines a
  371.    basic set of data types ("strings", "integers", "booleans", etc.);
  372.    instances of these data types are grouped in an application-defined
  373.    order to form USP blocks.  Each USP block is defined by a numeric
  374.    "block type"; a USP application can thus interpret a block's contents
  375.    based on knowledge of the block's type.  DMSP consists of a set of
  376.    operations, each of which is comprised of one or more different USP
  377.    blocks that are sent between repository and client.
  378.  
  379.    A DMSP session proceeds as follows: a client begins the session with
  380.    the repository by opening a USP connection to the repository's
  381.    machine.  The client then authenticates both itself and its user to
  382.    the repository with a "login" operation.  If the authentication is
  383.    successful, the user performs an arbitrary number of DMSP operations
  384.    before ending the session with a "logout" operation (at which time
  385.    the connection is closed by the repository).
  386.  
  387.    Because DMSP can manipulate a pair of mail states (local and global)
  388.    at once, it is extremely important that all DMSP operations are
  389.    failure-atomic.  Failure of any DMSP operation must leave both states
  390.    in a consistent, known state.  For this reason, a DMSP operation is
  391.    defined to have failed unless an explicit acknowledgement is received
  392.    by the operation initiator.  This acknowledgement can take one of two
  393.    basic forms, based on two broad categories that all DMSP operations
  394.    fall into.  First, an operation can be a request to perform some mail
  395.    state modification, in which case the repository will acknowledge the
  396.    request with either an "ok" or a "failure" (in which case the reason
  397.    for the failure is also returned).  Second, an operation can be a re-
  398.    quest for information, in which case the request is acknowledged by
  399.    the repository's providing the information to the client.  Operations
  400.    such as "delete a message" fall into the first category; operations
  401.    like "send a list of mailboxes" fall into the second category.
  402.  
  403.    Following is a general discussion of all the DMSP operations.  The
  404.    operations are broken down by type: general operations, user opera-
  405.    tions, client operations, mailbox operations, address operations,
  406.    bboard operations, and message operations.
  407.  
  408.  
  409.  
  410.  
  411. Clark & Lambert                                                 [Page 7]
  412.  
  413. RFC 993                                                    December 1986
  414.  
  415.  
  416. 4.1. General operations
  417.  
  418.    The first group of DMSP operations perform general functions that
  419.    operate on no one particular class of object.  DMSP has two general
  420.    operations, which provide the following services:
  421.  
  422.    In order to prevent protocol version skew between clients and the re-
  423.    pository, DMSP provides a "send-version" operation.  The client sup-
  424.    plies its DMSP version number as an argument; the operation succeeds
  425.    if the supplied version number matches the repository's DMSP version
  426.    number.  It fails if the two version numbers do not match.  The ver-
  427.    sion number is an unsigned quantity, like "100", "101", "200".  The
  428.    "send-version" operation should be the first that a client sends to
  429.    the repository, since no other operation my work if the client and
  430.    repository are using different versions of DMSP.
  431.  
  432.    Users can send mail to other users via the "send-message" operation.
  433.    The message must have an Internet-style header as defined by NIC
  434.    RFC-822.  The repository takes the message and distributes it to the
  435.    mailboxes specified on the "to:", "cc:", and "bcc:" fields of the
  436.    message header.  If one or more of the mailboxes exists outside the
  437.    repository's user community, the repository is responsible for hand-
  438.    ing the message to a local SMTP server.
  439.  
  440.    An OK is sent from the repository only if the entire message was suc-
  441.    cessfully transmitted.  If the message was destined for the Internet,
  442.    the send-message operation is successful if the message was success-
  443.    fully transmitted to the local SMTP server.
  444.  
  445. 4.2. User operations
  446.  
  447.    The next series of DMSP operations manipulates user objects.  The
  448.    most common of these operations are "login" and "logout".  A client
  449.    must perform a login operation before being able to access a user's
  450.    mail state.  A DMSP login block contains five items: (1) the user's
  451.    name, (2) the user's password, (3) the name of the client performing
  452.    the login, (4) a flag telling the repository to create a client ob-
  453.    ject for the client if one does not exist, and (5) a flag set to TRUE
  454.    if the client wishes to operate in "batch mode" and FALSE if the
  455.    client wishes to operate in "interactive" mode.  The flag value al-
  456.    lows the repository to tune internal parameters for either mode of
  457.    operation.
  458.  
  459.    The repository can return either an OK block (indicating successful
  460.    authentication), a FAILURE block (indicating failed authentication),
  461.    or a FORCE-RESET block.  This last is sent if the client logging in
  462.    has been marked as "inactive" by the repository (clients are marked
  463.    inactive if they have not connected to the repository in over a
  464.    week).  The FORCE-RESET block indicates that the client should erase
  465.    its local mail state and pull over a complete version of the
  466.    repository's mail state.  This is done on the assumption that so many
  467.  
  468.  
  469.  
  470. Clark & Lambert                                                 [Page 8]
  471.  
  472. RFC 993                                                    December 1986
  473.  
  474.  
  475.    mail state changes have been made in a week that it would be ineffi-
  476.    cient to perform a normal synchronization.
  477.  
  478.    When a client has completed a session with the repository, it per-
  479.    forms a logout operation.  This allows the repository to perform any
  480.    necessary cleanup before closing the USP connection.
  481.  
  482.    A user can change his password via the "set-password" operation.  The
  483.    operation works much the same as the UNIX change-password operation,
  484.    taking as arguments the user's current password and a desired new
  485.    password.  If the current password given matches the user's current
  486.    password, the user's current password is changed to the new password
  487.    given.
  488.  
  489. 4.3. Client operations
  490.  
  491.    DMSP provides four operations to manipulate client objects.  The
  492.    first, "list-clients", tells the repository to send the user's client
  493.    list to the requesting client.  The list takes the form of a series
  494.    of (client-name, status) pairs.  The status is either 0 (inactive) or
  495.    1 (active).
  496.  
  497.    The "create-client" operation allows a user to add a client object to
  498.    his list of client objects.  Although the login operation duplicates
  499.    this functionality via the "create-this-client?" flag, the add-client
  500.    operation is a useful means of creating a number of new client ob-
  501.    jects while logged into the repository via an existing client.  The
  502.    create-client operation requires the name of the client to add.
  503.  
  504.    The "delete-client" operation removes an existing client object from
  505.    a user's client list.  The client being removed cannot be in use by
  506.    anyone at the time.
  507.  
  508.    The last client operation, "reset-client", causes the repository to
  509.    mark all messages in the user's mail state as having changed since
  510.    the client last logged in.  When a client next synchronizes with the
  511.    repository, it will end up receiving a complete copy of the
  512.    repository's global mail state.  This is useful for two reasons.
  513.    First, a client's local mail state could easily become lost or dam-
  514.    aged, especially if it is stored on a floppy disk.  Second, if a
  515.    client has been marked as inactive by the repository, the reset-
  516.    client operation provides a fast way of resynchronizing with the re-
  517.    pository, assuming that so many differences exist between the local
  518.    and global mail states that a normal synchronization would take far
  519.    too much time.
  520.  
  521. 4.4. Mailbox operations
  522.  
  523.    DMSP supports five operations that manipulate mailbox objects.
  524.    First, "list-mailboxes" has the repository send to the requesting
  525.    client information on each mailbox.  This information consists of the
  526.  
  527.  
  528.  
  529. Clark & Lambert                                                 [Page 9]
  530.  
  531. RFC 993                                                    December 1986
  532.  
  533.  
  534.    mailbox name, total message count, unseen message count, and "next
  535.    available UID".  This operation is useful in synchronizing local and
  536.    global mail states, since it allows a client to compare the user's
  537.    global mailbox list with a client's local mailbox list.  The list of
  538.    mailboxes also provides a quick summary of each mailbox's contents
  539.    without having the contents present.
  540.  
  541.    The "create-mailbox" has the repository create a new mailbox and at-
  542.    tach it to the user's list of mailboxes.  An address object binding
  543.    the (user-name, mailbox-name) pair to an RFC-822-style address is au-
  544.    tomatically created and placed in the repository's list of address
  545.    objects.  This allows mail coming from the Internet to be correctly
  546.    routed to the new mailbox.
  547.  
  548.    "Delete-mailbox" removes a mailbox from the user's list of mailboxes.
  549.    All messages within the mailbox are also deleted and permanently re-
  550.    moved from the system.  Any address objects binding the mailbox name
  551.    to RFC-822-style mailbox addresses are also removed from the system.
  552.  
  553.    "Reset-mailbox" causes the repository to mark all the messages in a
  554.    named mailbox as having changed since the current client last saw
  555.    them.  When the client next synchronizes with the repository, it will
  556.    receive a complete copy of the named mailbox's mail state.  This
  557.    operation is merely a more specific version of the reset-client
  558.    operation (which allows the client to pull over a complete copy of
  559.    the user's global mail state).  Its primary use is for mailboxes
  560.    whose contents have accidentally been destroyed locally.
  561.  
  562.    Finally, DMSP has an "expunge-mailbox" operation.  Any message can be
  563.    deleted and "undeleted" at will.  Deletions are made permanent by
  564.    performing an expunge-mailbox operation.  The expunge operation
  565.    causes the repository to look through a named mailbox, removing from
  566.    the system any messages marked "deleted".
  567.  
  568. 4.5. Address operations
  569.  
  570.    DMSP provides three operations that allow users to manipulate address
  571.    objects.  First, the "list-address" operation returns a list of ad-
  572.    dress objects associated with a particular (user-name, mailbox-name)
  573.    pair.
  574.  
  575.    The "create-address" operation adds a new address object that associ-
  576.    ates a (user-name, mailbox-name) pair with a given RFC-822-style
  577.    mailbox address.
  578.  
  579.    Finally, the "delete-address" operation destroys the address object
  580.    binding the given RFC-822-style mail address and the given (user-
  581.    name, mailbox-name) pair.
  582.  
  583.  
  584.  
  585.  
  586.  
  587.  
  588. Clark & Lambert                                                [Page 10]
  589.  
  590. RFC 993                                                    December 1986
  591.  
  592.  
  593. 4.6. Bboard operations
  594.  
  595.    DMSP provides seven bulletin board operations.  The first, "list-
  596.    bboards", gives the user a list of the bboards he is currently sub-
  597.    scribing to.  The list contains an entry for each bboard that the
  598.    user subscribes to.  Each entry contains the following information:
  599.  
  600.       - The bulletin board's name
  601.  
  602.       - The UID of the first message the subscriber has not yet
  603.         seen
  604.  
  605.       - The highest message UID in the bulletin board
  606.  
  607.       - The number of messages the subscriber has not yet seen
  608.  
  609.    "List-all-bboards" gives the user a list of all bboards he can sub-
  610.    scribe to.
  611.  
  612.    "Create-bboard" allows a user to create a bboard mailbox.  The name
  613.    given must be unique across the entire repository user community.
  614.    Once the bboard mailbox has been created, other users may subscribe
  615.    to the bboard, using bboard objects to keep track of which messages
  616.    they have read on which bboards.
  617.  
  618.    "Delete-bboard" allows a bboard's owner to delete a bboard mailbox.
  619.    Subscribers who attempt to read from a bboard mailbox after it has
  620.    been deleted are told that the bboard no longer exists.
  621.  
  622.    DMSP also provides operations to subscribe to, and unsubscribe from,
  623.    any bboard.  "Subscribe-bboard" adds a bboard object to the users
  624.    bboard object list; "unsubscribe-bboard" removes a bboard object from
  625.    the list.  Note that this does not delete the bboard mailbox (obvi-
  626.    ously only the bboard's owner can do that).  It merely removes the
  627.    user from the list of the bboard's subscribers.
  628.  
  629.    DMSP allows for the user to tell the repository which messages in a
  630.    bboard he has seen.  Every bboard object contains the UID of the
  631.    first message the user has not yet seen; the "set-first-unread-
  632.    message-UID" operation updates that number, insuring that the user
  633.    sees a given bboard message only once.
  634.  
  635. 4.7. Message operations
  636.  
  637.    The most commonly-manipulated Pcmail objects are messages; DMSP
  638.    therefore provides special message operations to allow efficient syn-
  639.    chronization, as well as a set of operations to perform standard
  640.    message-manipulation functions.  In the following paragraphs, the
  641.    terms "message" and "descriptor" will be used interchangeably.
  642.  
  643.    A user may request a series of descriptors with the "get-descriptors"
  644.  
  645.  
  646.  
  647. Clark & Lambert                                                [Page 11]
  648.  
  649. RFC 993                                                    December 1986
  650.  
  651.  
  652.    operation.  The series is identified by a pair of message UIDs,
  653.    representing the lower and upper bounds of the list.  Since UIDs are
  654.    defined to be monotonically increasing numbers, a pair of UIDs is
  655.    sufficient to completely identify the series of descriptors.  If the
  656.    lower bound UID does not exist, the repository starts the series with
  657.    the first message with UID greater than the lower bound.  Similarly,
  658.    if the upper bound does not exist, the repository ends the series
  659.    with the last message with UID less than the upper bound.  If certain
  660.    UIDs within the series no longer exist, the repository (obviously)
  661.    does not send them.  The repository returns the descriptors in a se-
  662.    quence of "choices".  Elements of the sequence can either be descrip-
  663.    tors, in which case the choice is tagged as a descriptor, or they can
  664.    be notification that the requested message has been expunged subse-
  665.    quent to the client's last connection to the repository.  A descrip-
  666.    tor choice is a record containing the message's UID, flags, to, from,
  667.    date, and subject fields, length in bytes, and length in lines.  An
  668.    expunged choice contains only the expunged message's UID.
  669.  
  670.    The "get-changed-descriptors" operation is intended for use during
  671.    state synchronization.  Whenever a descriptor changes state (is
  672.    deleted, for example), the repository notes those clients which have
  673.    not yet recorded the change locally.  Get-changed-descriptors has the
  674.    repository send to the client a given number of descriptors which
  675.    have changed since the client's last synchronization.  The list sent
  676.    begins with the earliest-changed descriptor.  Note that the list of
  677.    descriptors is only guaranteed to be monotonically increasing for a
  678.    given call to "get-changed-descriptors"; messages with lower UIDs may
  679.    be changed by other clients in between calls to "get-changed-
  680.    descriptors".
  681.  
  682.    Once the changed descriptors have been looked at, a user will want to
  683.    inform the repository that the current client has recorded the change
  684.    locally.  The "reset-changed-descriptors" causes the repository to
  685.    mark as "seen by current client" a given series of descriptors.  The
  686.    series is identified by a low UID and a high UID.  UIDs within the
  687.    series that no longer exist are not reset.
  688.  
  689.    Message bodies are transmitted from repository to user with the
  690.    "get-message-text" operation.  The separation of "get-descriptors"
  691.    and "get-message-text" operations allows clients with small amounts
  692.    of disk storage to obtain a small message summary (via "get-
  693.    descriptors" or "get-changed-descriptors") without having to pull
  694.    over the entire message.
  695.  
  696.    Frequently, a message may be too large for some clients to store lo-
  697.    cally.  Users can still look at the message contents via the "print-
  698.    message" operation.  This operation has the repository send a copy of
  699.    the message to a named printer.  The printer name need only have
  700.    meaning to the particular repository implementation; DMSP transmits
  701.    the name only as a means of identification.
  702.  
  703.  
  704.  
  705.  
  706. Clark & Lambert                                                [Page 12]
  707.  
  708. RFC 993                                                    December 1986
  709.  
  710.  
  711.    Copying of one message into another mailbox is accomplished via the
  712.    "copy-message" operation.  A descriptor list of length one, contain-
  713.    ing a descriptor for the copied message is returned if the copy
  714.    operation is successful.  This descriptor is required because the
  715.    copied message acquires a UID different from the original message.
  716.    The client cannot be expected to know which UID has been assigned the
  717.    copy, hence the repository's sending a descriptor containing the UID.
  718.  
  719. 5. Client Architecture
  720.  
  721.    Clients can be any of a number of different workstations; Pcmail's
  722.    architecture must therefore take into account the range of charac-
  723.    teristics of these workstations.  First, most workstations are much
  724.    more affordable than the large computers currently used for mail ser-
  725.    vice.  It is therefore possible that a user may well have more than
  726.    one.  Second, some workstations are portable and they are not expect-
  727.    ed to be constantly tied into a network.  Finally, many of the small-
  728.    er workstations resource-poor, so they are not expected to be able to
  729.    store a significant amount of state information locally.  The follow-
  730.    ing subsections describe the particular parts of Pcmail's client ar-
  731.    chitecture that address these different characteristics.
  732.  
  733. 5.1. Multiple clients
  734.  
  735.    The fact that Pcmail users may own more than one workstation forms
  736.    the rationalization for the multiple client model that Pcmail uses.
  737.    A Pcmail user may have one client at home, another at an office, and
  738.    maybe even a third portable client.  Each client maintains a separate
  739.    copy of the user's mail state, hence Pcmail's distributed nature.
  740.    The notion of separate clients allows Pcmail users to access mail
  741.    state from several different locations.  Pcmail places no restric-
  742.    tions on a user's ability to communicate with the repository from
  743.    several clients at the same time.  Instead, the decision to allow
  744.    several clients concurrent access to a user's mail state is made by
  745.    the repository implementation.
  746.  
  747. 5.2. Synchronization
  748.  
  749.    Some workstations tend to be small and fairly portable; the likeli-
  750.    hood of their always being connected to a network is relatively
  751.    small.  This is another reason for each client's maintaining a local
  752.    copy of a user's mail state.  The user can then manipulate the local
  753.    mail state while not connected to the network (and the repository).
  754.    This immediately brings up the problem of synchronization between lo-
  755.    cal and global mail states.  The repository is continually in a posi-
  756.    tion to receive global mail state updates, either in the form of in-
  757.    coming mail, or in the form of changes from other clients.  A client
  758.    that is not always connected to the net cannot immediately receive
  759.    the global changes.  In addition, the client's user can make his own
  760.    changes on the local mail state.
  761.  
  762.  
  763.  
  764.  
  765. Clark & Lambert                                                [Page 13]
  766.  
  767. RFC 993                                                    December 1986
  768.  
  769.  
  770.    Pcmail's architecture allows fast synchronization between client lo-
  771.    cal mail states and the repository's global mail state.  Each client
  772.    is identified in the repository by a client object attached to the
  773.    user.  This object forms the basis for synchronization between local
  774.    and global mail states.  Some of the less common state changes in-
  775.    clude the adding and deleting of user mailboxes and the adding and
  776.    deleting of address objects.  Synchronization of these changes is
  777.    performed via DMSP list operations, which allow clients to compare
  778.    their local versions of mailbox and address object lists with the
  779.    repository's global version and make any appropriate changes.  The
  780.    majority of possible changes to a user's mail state are in the form
  781.    of changed descriptors.  Since most users will have a large number of
  782.    messages, and message states will change relatively often, special
  783.    attention needs to be paid to message synchronization.
  784.  
  785.    An existing descriptor can be changed in one of two ways: first, one
  786.    of its sixteen flags values can be changed (this encompasses reading
  787.    an unseen message, deleting a message, and expunging a message).  The
  788.    second way to change a descriptor is via the arrival of incoming mail
  789.    or the copying of a message from one mailbox to another.  Both result
  790.    in a new message being added to a mailbox.
  791.  
  792.    In both the above cases, synchronization is required between the re-
  793.    pository and every client that has not previously noted a change.  To
  794.    keep track of which clients have noticed a global mail state change
  795.    and changed their local states accordingly, each mailbox has associ-
  796.    ated with it a list of active clients.  Each client has a (potential-
  797.    ly empty) "update list" of messages which have changed since that
  798.    client last read them.
  799.  
  800.    When a client connects to the repository, it executes a DMSP "get-
  801.    changed-descriptors" operation.  This causes the repository to return
  802.    a list of all descriptor objects on that client's update list As the
  803.    client receives the changed descriptors, it can store them locally,
  804.    thus updating the local mail state.  After a changed descriptor has
  805.    been recorded, the client uses the DMSP "reset-descriptors" operation
  806.    to remove the message from its update list.  That descriptor will now
  807.    not be sent to the client unless (1) it is explicitly requested, or
  808.    (2) it changes again.
  809.  
  810.    In this manner, a client can run through its user's mailboxes, get-
  811.    ting all changed descriptors, incorporating them into the local mail
  812.    state, and marking the change as recorded.
  813.  
  814. 5.3. Batch operation versus interactive operation
  815.  
  816.    Because of the portable nature of some workstations, they may not al-
  817.    ways be connected to a network (and able to communicate with the re-
  818.    pository).  Since each client maintains a local mail state, Pcmail
  819.    users can manipulate the local state while not connected to the repo-
  820.    sitory.  This is known as "batch" operation, since all changes are
  821.  
  822.  
  823.  
  824. Clark & Lambert                                                [Page 14]
  825.  
  826. RFC 993                                                    December 1986
  827.  
  828.  
  829.    recorded by the client and made to the repository's global state in a
  830.    batch, when the client next connects to the repository.  Interactive
  831.    operation occurs when a client is always connected to the repository.
  832.    In interactive mode, changes made to the local mail state are also
  833.    immediately made to the global state via DMSP operations.
  834.  
  835.    In batch mode, interaction between client and repository takes the
  836.    following form:  the client connects to the repository and sends over
  837.    all the changes made by the user to the local mail state.  The repo-
  838.    sitory changes its global mail state accordingly.  When all changes
  839.    have been processed, the client begins synchronization, to incor-
  840.    porate newly-arrived mail, as well as mail state changes by other
  841.    clients, into the local state.
  842.  
  843.    In interactive mode, since local changes are immediately propagated
  844.    to the repository, the first part of batch-type operation is elim-
  845.    inated.  The synchronization process also changes; although one syn-
  846.    chronization is required when the client first opens a connection to
  847.    the repository, subsequent synchronizations can be performed either
  848.    at the user's request or automatically every so often by the client.
  849.  
  850. 5.4. Message summaries
  851.  
  852.    Smaller workstations may have little in the way of disk storage.
  853.    Clients running on these workstations may never have enough room for
  854.    a complete local copy of a user's global mail state.  This means that
  855.    Pcmail's client architecture must allow user's to obtain a clear pic-
  856.    ture of their mail state without having all their messages present.
  857.  
  858.    Descriptors provide message information without taking up large
  859.    amounts of storage.  Each descriptor contains a summary of informa-
  860.    tion on a message.  This information includes the message UID, its
  861.    length in bytes and lines, its status (encoded in the eight system-
  862.    defined and eight user-defined flags), and portions of its RFC-822
  863.    header (the "to:", "from:", "subject:" and "date:" fields).  All of
  864.    this information can be encoded in a small (around 100 bytes) data
  865.    structure whose length is independent of the size of the message it
  866.    describes.
  867.  
  868.    Most clients should be able to store a complete list of message
  869.    descriptors with little problem.  This allows a user to get a com-
  870.    plete picture of his mail state without having all his messages
  871.    present locally.  If a client has extremely limited amounts of disk
  872.    storage, it is also possible to get a subset of the descriptors from
  873.    the repository.  Short messages can reside on the client, along with
  874.    the descriptors, and long messages can either be printed via the DMSP
  875.    print-message operation, or specially pulled over via the fetch-
  876.    message-text operation.
  877.  
  878.  
  879.  
  880.  
  881.  
  882.  
  883. Clark & Lambert                                                [Page 15]
  884.  
  885. RFC 993                                                    December 1986
  886.  
  887.  
  888. 6. Typical interactive-style client-repository interaction
  889.  
  890.    The following example describes a typical communication session
  891.    between the repository and a client.  The client is one of three be-
  892.    longing to user "Fred".  Its name is "office-client", and since Fred
  893.    uses the client regularly to access his mail, the client is marked as
  894.    "active".  Fred has two mailboxes: "main" is where all of his current
  895.    mail is stored; "archive" is where messages of lasting importance are
  896.    kept.  The example will run through a simple synchronization opera-
  897.    tion followed by a series of typical mail state manipulations.  Typi-
  898.    cally, the synchronization will be performed by an application pro-
  899.    gram that connects to the repository, logs in, synchronizes, and logs
  900.    out.
  901.  
  902.    For the example, all DMSP operations will be shown in a user-readable
  903.    format.  In reality, the operations would be sent as a stream of USP
  904.    blocks consisting of a block-type number followed by a stream of
  905.    bytes representing the block's components.
  906.  
  907.    In order to access his global mail state, the client software must
  908.    authenticate Fred to the repository; this is done via the DMSP login
  909.    operation:
  910.  
  911.        login ["fred", "fred-password", "office-client", F, F]
  912.  
  913.    This tells the repository that Fred is logging in via "office-
  914.    client", and that "office-client" is identified by an existing client
  915.    object attached to Fred's user object.  The first component of the
  916.    login block is Fred's repository user name.  The second component is
  917.    Fred's password.  The third component is the name of the client com-
  918.    municating with the repository.  The fourth component tells the repo-
  919.    sitory not to create "office-client" even if it cannot find its
  920.    client object.  The final component tells the repository that Fred's
  921.    client is not operating in batch mode but rather in interactive mode.
  922.  
  923.    Fred's authentication checks out, so the repository logs him in, ack-
  924.    nowledging the login request with an OK block.
  925.  
  926.    Now that Fred is logged in, the client performs an initial synchroni-
  927.    zation.  This process starts with the client's asking for an up-to-
  928.    date list of mailboxes:
  929.  
  930.        list-mailboxes []
  931.  
  932.         The repository replies with:
  933.  
  934.        mailbox-list [["main", 10, 1, 253],
  935.                      ["archive", 100, 0, 101]]
  936.  
  937.    This tells the client that there are two mailboxes, "main" and "ar-
  938.    chive".  "Main" has 10 messages, one of which is unseen.  The next
  939.  
  940.  
  941.  
  942. Clark & Lambert                                                [Page 16]
  943.  
  944. RFC 993                                                    December 1986
  945.  
  946.  
  947.    incoming message will be assigned a UID of 253.  "Archive", on the
  948.    other hand, has 100 message, none of which are unseen.  The next mes-
  949.    sage sent to "archive" will be assigned the UID 101.  There are no
  950.    new mailboxes in the list (if there were, the client program would
  951.    create them.  On the other hand, if some mailboxes in the client's
  952.    local list were not in the repository's list, the program would as-
  953.    sume them deleted by another client and delete them locally as well).
  954.  
  955.    To synchronize the client need only look at each mailbox's contents
  956.    to see if (1) any new mail has arrived, or (2) if Fred changed any
  957.    messages on one of his other two clients subsequent to "office-
  958.    client"'s last connection to the repository.
  959.  
  960.    The client asks for any changed descriptors via the "get-changed-
  961.    descriptors" operation.  It requests at most ten changed descriptors
  962.    since storage is very limited on "office-client".
  963.  
  964.        get-changed-descriptors ["main", 10]
  965.  
  966.         The repository responds with:
  967.  
  968.        descriptor-list [[descriptor[
  969.                                 6,
  970.                                 [T T F F F F F F F F F F
  971.                                  F F F F],
  972.                                 "Fred@borax",
  973.                                 "Joe@fab",
  974.                                 "Wed, 23 Jan 86 11:11 EST",
  975.                                 "tomorrow's meeting",
  976.                                 621,
  977.                                 10]]
  978.                          [descriptor[
  979.                                 10,
  980.                                 [F T F F F F F F F F F F
  981.                                  F F F F],
  982.                                 "Fred",
  983.                                 "Freds-secretary",
  984.                                 "Fri, 25 Jan 86 11:11 EST",
  985.                                 "Monthly progress report",
  986.                                 13211,
  987.                                 350]]
  988.                            ]
  989.  
  990.    The first descriptor in the list is one which Fred deleted on another
  991.    client yesterday.  "Office-client" marks the local version of the
  992.    message as deleted.  The second descriptor in the list is a new one.
  993.    "Office-client" adds the descriptor to its local list.  Since both
  994.    changes have now been recorded locally, the descriptors can be reset:
  995.  
  996.        reset-descriptors ["main", 6, 10]
  997.  
  998.  
  999.  
  1000.  
  1001. Clark & Lambert                                                [Page 17]
  1002.  
  1003. RFC 993                                                    December 1986
  1004.  
  1005.  
  1006.    The repository removes from "office-client"'s update list all mes-
  1007.    sages with UIDs between 6 and 10 (in this case just two messages)
  1008.    "Main" has now been synchronized.  The client now turns to Fred's
  1009.    "archive" mailbox and asks for the first ten changed descriptors.
  1010.  
  1011.        get-changed-descriptors ["archive", 10]
  1012.  
  1013.         The repository responds with
  1014.  
  1015.        descriptor-list []
  1016.  
  1017.    The zero-length list tells "office-client" that no descriptors have
  1018.    been changed in "archive" since its last synchronization.  No new
  1019.    synchronization needs to be performed.
  1020.  
  1021.    Fred's client is now ready to pull over the new message.  The message
  1022.    is 320 lines long; there might not be sufficient storage on "office-
  1023.    client" to hold the new message.  The client tries anyway:
  1024.  
  1025.        fetch-message-text ["main", 10]
  1026.  
  1027.         The repository begins transmitting the message:
  1028.  
  1029.        message ["From: Fred's-secretary",
  1030.                 "To: Fred",
  1031.                 "Subject: Monthly progress report",
  1032.                 "Date: Fri, 25 Jan 86 11:11 EST",
  1033.                 "",
  1034.                 "Dear Fred,",
  1035.                 "Here is this month's progress report",
  1036.                 ...
  1037.                 ]
  1038.  
  1039.    Halfway through the message transmission, "office-client" runs out of
  1040.    disk space.  Because all DMSP operations are defined to be failure-
  1041.    atomic, the portion of the message already transmitted is destroyed
  1042.    locally and the operation fails.  "Office-client" informs Fred that
  1043.    the message cannot be pulled over because of a lack of disk space.
  1044.    The synchronization process is now finished and Fred can start read-
  1045.    ing his mail.  The new message that was too big to fit on "office-
  1046.    client" will be marked "off line"; Fred can either remote-print it or
  1047.    delete other messages until he has enough space to store the new mes-
  1048.    sage.
  1049.  
  1050.    Since he is running in interactive mode, changes he makes to any mes-
  1051.    sages will immediately be transmitted into DMSP operations and sent
  1052.    to the repository.  Depending on the client implementation, Fred will
  1053.    either have to execute a "synchronize" command periodically or the
  1054.    client will synchronize for him automatically every so often.
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060. Clark & Lambert                                                [Page 18]
  1061.  
  1062. RFC 993                                                    December 1986
  1063.  
  1064.  
  1065. 7. A current Pcmail implementation
  1066.  
  1067.    The following section briefly describes a current Pcmail system that
  1068.    services a small community of users.  The Pcmail repository runs
  1069.    under UNIX on a DEC VAX-750 connected to the Internet.  The clients
  1070.    run on IBM PCs, XTs, and ATs, as well as Sun workstations, Micro-
  1071.    vaxes, and VAX-750s.
  1072.  
  1073. 7.1. IBM PC client code
  1074.  
  1075.    Client code for the IBM machines operates only in batch mode.  Users
  1076.    make local state changes, which are queued until the client connects
  1077.    to the repository.  At that time, the changes are performed and the
  1078.    local and global states synchronized.  The client then disconnects
  1079.    from the repository.
  1080.  
  1081.    Users access and modify their local mail state via a user interface
  1082.    program.  The program uses windows and a full-screen mode of opera-
  1083.    tion.  Users are given a variety of commands to operate on individual
  1084.    messages as well as mailboxes.  The interface allows use of any text
  1085.    editor to compose messages, and adds features of its own to make
  1086.    RFC-822-style header composition easier.
  1087.  
  1088.    Synchronization and the processing of queued changes is performed by
  1089.    a separate program, which the user runs whenever he wishes.  The pro-
  1090.    gram takes any actions queued while operating the user interface, and
  1091.    converts them into DMSP operations.  All queued changes are made be-
  1092.    fore any synchronization is performed.
  1093.  
  1094.    The limitation of IBM PC client operation to batch mode was made be-
  1095.    cause of development environment limitations.  The user interface
  1096.    could not work with the network code inside it due to program size
  1097.    limitations.  Since MS-DOS has no multi-processing facilities, the
  1098.    two programs could not run in tandem either.  The only solution was
  1099.    to provide a two-part client, one part of which read the mail and one
  1100.    part of which interacted with the repository.
  1101.  
  1102. 7.2. UNIX client code
  1103.  
  1104.    Client code for the Suns, Microvaxes, and VAX-750s runs on 4.2/4.3BSD
  1105.    UNIX.  It is fully interactive, with a powerful user interface inside
  1106.    Richard Stallman's GNU-EMACS editor.  Since UNIX-based workstations
  1107.    have a good deal of main memory and disk storage, no effort was made
  1108.    to lower local mail state size by keeping message descriptors rather
  1109.    than message text.
  1110.  
  1111.    The local mail state consists of a number of BABYL-format mailboxes.
  1112.    The interface is very similar to the RMAIL mail reader already
  1113.    present in GNU-EMACS.
  1114.  
  1115.    The user interface communicates with the repository through a DMSP
  1116.  
  1117.  
  1118.  
  1119. Clark & Lambert                                                [Page 19]
  1120.  
  1121. RFC 993                                                    December 1986
  1122.  
  1123.  
  1124.    implementation built into the GNU-EMACS kernel.  Changes to the local
  1125.    mail state are immediately made on the repository; the repository is
  1126.    fast enough that there is little noticeable delay in performing the
  1127.    operation over the network.
  1128.  
  1129.    There is no provision for automatic synchronization whenever new mail
  1130.    arrives or old mail is changed by another client.  Instead, users
  1131.    must get any new mail explicitly.  A simple "notification" program
  1132.    runs in the background and wakes up every minute to check for new
  1133.    mail; when mail arrives, the user executes a command to get the new
  1134.    mail, synchronizing the mailbox at the same time.
  1135.  
  1136. 7.3. Repository code
  1137.  
  1138.    The repository is implemented in C on 4.2/4.3BSD UNIX.  Currently it
  1139.    runs on DEC VAX-750s and Microvaxes, although other repositories will
  1140.    soon be running on IBM RT machines and Sun workstations.  The reposi-
  1141.    tory code is designed to allow several clients belonging to a partic-
  1142.    ular user to "concurrently" modify the user's state.  A mailbox lock-
  1143.    ing scheme prevents one client from modifying a mailbox while another
  1144.    client is modifying the same mailbox.
  1145.  
  1146. 8. Conclusions
  1147.  
  1148.    Pcmail is now used by a small community of people at the MIT Labora-
  1149.    tory for Computer Science.  The repository design works well, provid-
  1150.    ing an efficient means of storing and maintaining mail state for
  1151.    several users.  Its performance is quite good when up to ten users
  1152.    are connected; it remains to be seen whether or not the repository
  1153.    will be efficient at managing the state of ten or a hundred times
  1154.    that many users.  Given sufficient disk storage, it should be able
  1155.    to, since communication between different users' clients and the re-
  1156.    pository is likely to be very asynchronous and likely to occur in
  1157.    short bursts with long "quiet intervals" in between as users are busy
  1158.    doing other things.
  1159.  
  1160.    Members of another research group at LCS are currently working on a
  1161.    replicated, scalable version of the repository designed to support a
  1162.    very large community of users with high availability.  This reposito-
  1163.    ry also uses DMSP and has successfully communicated with clients that
  1164.    use the current repository implementation.  DMSP therefore seems to
  1165.    be usable over several flavors of repository design.
  1166.  
  1167.    The IBM PC clients are unfortunately very limited in the way of
  1168.    resources, making local mail state manipulation difficult at times.
  1169.    Synchronization is also relatively time consuming due to the low per-
  1170.    formance of the PCs.  The "batch-mode" that the PCs use tends to be
  1171.    good for those PCs that spend a large percentage of their time un-
  1172.    plugged and away from a network.  It is somewhat inconvenient for
  1173.    those PCs that are always connected to a network and could make good
  1174.    use of an "interactive-mode" state manipulation.
  1175.  
  1176.  
  1177.  
  1178. Clark & Lambert                                                [Page 20]
  1179.  
  1180. RFC 993                                                    December 1986
  1181.  
  1182.  
  1183.    The UNIX-based clients are far easier to use than their PC counter-
  1184.    parts.  Synchronization is much faster, and there is far more func-
  1185.    tionality in the user interface (having an interface that runs within
  1186.    GNU-EMACS helps a lot in this respect).  Most of those people using
  1187.    the Pcmail system use the UNIX-based client code.
  1188.  
  1189.  
  1190.                                  APPENDIX
  1191.  
  1192.  
  1193. A. DMSP Protocol Specification
  1194.  
  1195.    Following are a list of DMSP operations by object type, their block
  1196.    types and arguments, and their expected acknowledgement block types.
  1197.    Each DMSP block has a different number; the first digit of each block
  1198.    type defines the object being manipulated: Operations numbered 5xx
  1199.    are general, operations numbered 6xx are user operations, operations
  1200.    numbered 7xx are client operations, operations numbered 8xx are mail-
  1201.    box operations, operations numbered 9xx are address operations,
  1202.    operations numbered 10xx are bboard operations, and operations num-
  1203.    bered 11xx are message operations.
  1204.  
  1205.    Failure blocks contain two fields, a "code" and a "why".  The "code"
  1206.    is an unsigned number placing the error in one of several broad
  1207.    categories (listed below).  The "why" is a text string, possibly ex-
  1208.    plaining the error in greater detail.
  1209.  
  1210.         Error codes:
  1211.  
  1212.         - 1: network error while reading or writing data
  1213.  
  1214.         - 2: internal repository error.  This can be due to lack
  1215.              of memory, a fatal bug, lack of disk space, etc.
  1216.  
  1217.         - 3: requested object already exists.  For example, you
  1218.              tried to create a mailbox that already exists
  1219.  
  1220.         - 4: requested object not found.  For example, you tried
  1221.              to delete a message or a mailbox that doesn't exist.
  1222.  
  1223.         - 5: protocol error.  Typically DMSP protocol version
  1224.              skew.
  1225.  
  1226.         - 6: block argument error.  For example, a "set-message-flag"
  1227.              operation was attempted on a bboard by someone
  1228.              other than the bboard's owner.
  1229.  
  1230.         - 7: data read error.  The repository was unable to read
  1231.              the mail state information requested.
  1232.  
  1233.  
  1234.  
  1235.  
  1236.  
  1237. Clark & Lambert                                                [Page 21]
  1238.  
  1239. RFC 993                                                    December 1986
  1240.  
  1241.  
  1242.         - 8: data write error.  The repository was unable to
  1243.              write out changed mail state information, perhaps
  1244.              because the disk was full.
  1245.  
  1246.         - 9: operating system error:  Should be reserved for
  1247.              things like fork or pipe call errors.
  1248.  
  1249.         - 10: unexpected or unknown block type received.  For
  1250.               example, you sent a "delete-mailbox" block and received
  1251.               a "mailbox-list" block in response.
  1252.  
  1253.    Blocks marked "=>" flow from client to repository; blocks marked "<="
  1254.    flow from repository to client.  If more than one block can be sent,
  1255.    the choices are delimited by "or" ("|") characters.
  1256.  
  1257.    For clarity, each block type is put in a human-understandable form.
  1258.    The block number is followed by an operation name; this name is never
  1259.    transmitted as part of a USP block.  Block arguments are identified
  1260.    by name and type, and enclosed in square brackets.  "Record" data
  1261.    types are described by a list of "field-name:field-type" pairs con-
  1262.    tained in square brackets.  "Choice" data types are described by a
  1263.    list of "tag-name:tag-type" pairs contained in square brackets.  USP
  1264.    data types are defined as follows (the definitions are brief; refer
  1265.    to the USP specification for more detailed descriptions):
  1266.  
  1267. A.1. Primitive data types
  1268.  
  1269.    string (S): a series of bytes, null-byte padded to even length and
  1270.    preceded by a 16-bit length specifier.  Strings are sent in "net-
  1271.    ascii" format (newline sequence is carriage return followed by
  1272.    linefeed, single carriage returns to be followed by a null byte).
  1273.  
  1274.         - cardinal (C): a 16-bit unsigned number.
  1275.  
  1276.         - long-cardinal (LC): a 32-bit unsigned number.
  1277.  
  1278.         - integer (I): a 16-bit signed number.
  1279.  
  1280.         - long-integer (LI): a 32-bit signed number.
  1281.  
  1282.         - boolean (B): a 16-bit number with either a 1 or a 0 in the
  1283.           16th bit.
  1284.  
  1285. A.2. Compound data types
  1286.  
  1287.         - sequence (SEQ): A list of data items, all the same type and
  1288.           preceded by a 16-bit sequence length specifier.
  1289.  
  1290.  
  1291.  
  1292.  
  1293.  
  1294.  
  1295.  
  1296. Clark & Lambert                                                [Page 22]
  1297.  
  1298. RFC 993                                                    December 1986
  1299.  
  1300.  
  1301.         - array (AR): A fixed-length list of data items, all the same
  1302.           type.  A particular array's length is fixed by the application.
  1303.  
  1304.         - record (REC): A list of data items of any type.  A
  1305.           particular record's format is fixed by the application.
  1306.  
  1307.         - choice (CH): One of a list of possible data types.  The data
  1308.           type contained in the choice is identified by a 16-bit numeric
  1309.           tag.  The application interprets the data item based on the tag
  1310.           value.
  1311.  
  1312.  
  1313. A.3. DMSP Abstract Data Types
  1314.  
  1315.      Following are data types defined and used only by DMSP:
  1316.  
  1317.      - client: a record with the following format:
  1318.        REC[name:S, status:C] Status is either 1 (active) or 0
  1319.        (inactive)
  1320.  
  1321.      - mailbox: a record with the following format:
  1322.        REC[name:S, next-uid:LC, #msgs:C, #new-msgs:C]
  1323.  
  1324.      - bboard: a record with the following format:
  1325.        REC[name:S, first-unread-message-UID:LC
  1326.        number-of-unseen-messages:C highest-UID:LC]
  1327.  
  1328.      - descriptor: a record with the following format:
  1329.  
  1330.      - REC[UID:LC, flags:SEQ[B], from, to, date, subject:S,
  1331.        #bytes:LC, #lines:LC]
  1332.  
  1333.      - desc-choice: a choice with the following format:
  1334.        CH[expunged-message-UID:LC, desc:descriptor] Descriptor
  1335.        tag number is 1.  Expunged-message tag number is 0.
  1336.  
  1337. A.4. General operations
  1338.  
  1339.      => 502 (send-version) [version:C]
  1340.      <= 500 (ok) [] |
  1341.         501 (failure) [code:C, why:S]
  1342.  
  1343.  
  1344.      => 503 (send-message) [message:SEQ[S]]
  1345.      <= 500 (ok) [] |
  1346.         501 (failure) [code:C, why:S]
  1347.  
  1348.  
  1349.  
  1350.  
  1351.  
  1352.  
  1353.  
  1354.  
  1355. Clark & Lambert                                                [Page 23]
  1356.  
  1357. RFC 993                                                    December 1986
  1358.  
  1359.  
  1360. A.5. User operations
  1361.  
  1362.      => 600 (login) [name:S, password:S, client:S,
  1363.                      create-client-object?:B
  1364.                      batch-mode?:B]
  1365.      <= 500 (ok) [] |
  1366.         501 (failure) [code:C, why:S] |
  1367.         705 (force-client-reset) []
  1368.  
  1369.  
  1370.      => 601 (logout) []
  1371.      <= 500 (ok) []
  1372.  
  1373.  
  1374.      => 602 (set-password) [old:S, new:S]
  1375.      <= 500 (ok) [] |
  1376.         501 (failure) [code:C, why:S]
  1377.  
  1378. A.6. Client operations
  1379.  
  1380.      => 701 (list-clients) []
  1381.      <= 700 (client-list) [client-list:SEQ[client]]
  1382.  
  1383.  
  1384.      => 702 (create-client) [client:S]
  1385.      <= 500 (ok) [] |
  1386.         501 (failure) [code:C, why:S]
  1387.  
  1388.      => 703 (delete-client) [client:S]
  1389.      <= 500 (ok) [] |
  1390.         501 (failure) [code:C, why:S]
  1391.  
  1392.  
  1393.      => 704 (reset-client) [client:S]
  1394.      <= 500 (ok) [] |
  1395.         501 (failure) [code:C, why:S]
  1396.  
  1397. A.7. Mailbox operations
  1398.  
  1399.      => 801 (list-mailboxes) []
  1400.      <= 800 (mailbox-list) [mailbox-list:SEQ[mailbox]]
  1401.  
  1402.  
  1403.      => 802 (create-mailbox) [mailbox:S]
  1404.      <= 500 (ok) [] |
  1405.         501 (failure) [code:C, why:S]
  1406.  
  1407.  
  1408.      => 803 (delete-mailbox) [mailbox:S]
  1409.      <= 500 (ok) [] |
  1410.         501 (failure) [code:C, why:S]
  1411.  
  1412.  
  1413.  
  1414. Clark & Lambert                                                [Page 24]
  1415.  
  1416. RFC 993                                                    December 1986
  1417.  
  1418.  
  1419.      => 804 (reset-mailbox) [mailbox:S]
  1420.      <= 500 (ok) [] |
  1421.         501 (failure) [code:C, why:S]
  1422.  
  1423.  
  1424.      => 805 (expunge-mailbox) [mailbox:S]
  1425.      <= 500 (ok) [] |
  1426.         501 (failure) [code:C, why:S
  1427.  
  1428. A.8. Address operations
  1429.  
  1430.      => 901 (list-addresses) [mailbox:S]
  1431.      <= 501 (failure) [code:C, why:S] |
  1432.         900 (address-list) [address-list:SEQ[S]]
  1433.  
  1434.  
  1435.      => 902 (create-address) [mailbox:S, address:S]
  1436.      <= 500 (ok) [] |
  1437.         501 (failure) [code:C, why:S]
  1438.  
  1439.  
  1440.      => 903 (delete-address) [mailbox:S, address:S]
  1441.      <= 500 (ok) [] |
  1442.         501 (failure) [code:C, why:S]
  1443.  
  1444. A.9. Bboard operations
  1445.  
  1446.      => 1001 (list-bboards) []
  1447.      <= 1000 (bboard-list) [bboard-list:SEQ[bboard]]
  1448.         501 (failure) [code:C, why:S]
  1449.  
  1450.  
  1451.      => 1002 (create-bboard) [name:S]
  1452.      <= 500 (ok) [] |
  1453.         501 (failure) [code:C, why:S]
  1454.  
  1455.  
  1456.      => 1003 (delete-bboard) [name:S]
  1457.      <= 500 (ok) [] |
  1458.         501 (failure) [code:C, why:S]
  1459.  
  1460.  
  1461.      => 1004 (subscribe-bboard) [name:S]
  1462.      <= 500 (ok) [] |
  1463.         501 (failure) [code:C, why:S]
  1464.  
  1465.  
  1466.      => 1005 (unsubscribe-bboard) [name:S]
  1467.      <= 500 (ok) [] |
  1468.         501 (failure) [code:C, why:S]
  1469.  
  1470.  
  1471.  
  1472.  
  1473. Clark & Lambert                                                [Page 25]
  1474.  
  1475. RFC 993                                                    December 1986
  1476.  
  1477.  
  1478.      => 1006 (set-bboard-first-unread) [name:S, UID:LC]
  1479.      <= 500 (ok) [] |
  1480.         501 (failure) [code:C, why:S]
  1481.  
  1482.      => 1007 (list-all-bboards) []
  1483.      <= 1008 (bboard-name-list) [bboard-name-list:SEQ[S]]
  1484.         501 (failure) [code:C, why:S]
  1485.  
  1486. A.10. Message operations
  1487.  
  1488.      => 1102 (get-descriptors) [mailbox:S,
  1489.                                 low-uid:LC,
  1490.                                 high-uid:LC]
  1491.      <= 501 (failure) [code:C, why:S] |
  1492.         1100 (desc-list) [desc-list:SEQ[desc-choice]]
  1493.  
  1494.  
  1495.      => 1103 (get-changed-descriptors) [mailbox:S,
  1496.                                         max-to-send:C]
  1497.      <= 501 (failure) [code:C, why:S] |
  1498.         1100 (desc-list) [desc-list:SEQ[desc-choice]]
  1499.  
  1500.  
  1501.      => 1104 (reset-changed-descriptors) [
  1502.                      mailbox:S,
  1503.                      start-uid:LC,
  1504.                      end-uid:LC]
  1505.      <= 500 (ok) [] |
  1506.         501 (failure) [code:C, why:S]
  1507.  
  1508.  
  1509.      => 1105 (get-message-text) [mailbox:S,
  1510.                                  uid:LC]
  1511.      <= 501 (failure) [code:C, why:S] |
  1512.         1101 (message) [message:SEQ[S]]
  1513.  
  1514.  
  1515.      => 1106 (print-message) [mailbox:S,
  1516.                               uid:LC,
  1517.                               printer-name:S]
  1518.      <= 500 (ok) [] |
  1519.         501 (failure) [code:C, why:S]
  1520.  
  1521.  
  1522.      => 1107 copy-message[source-mailbox:S,
  1523.                           target-mailbox:S,
  1524.                           source-uid:LC]
  1525.      <= 501 (failure) [code:C, why:S]
  1526.      <= 501 (failure) [code:C, why:S] |
  1527.         1100 (desc-list) [desc-list:SEQ[desc-choice]]
  1528.  
  1529.  
  1530.  
  1531.  
  1532. Clark & Lambert                                                [Page 26]
  1533.  
  1534. RFC 993                                                    December 1986
  1535.  
  1536.  
  1537.      => 1108 (set-flag) [mailbox:S,
  1538.                          uid:LC,
  1539.                          flag-number:C,
  1540.                          flag-setting:B]
  1541.      <= 500 (ok) [] |
  1542.         501 (failure) [code:C, why:S]                               30
  1543.  
  1544.           DMSP block types by number
  1545.  
  1546.      General block types
  1547.  
  1548.      ok                      500
  1549.      failure                 501
  1550.      send-version            502
  1551.      send-message            503
  1552.  
  1553.      User operation block types
  1554.  
  1555.      login                   600
  1556.      logout                  601
  1557.      set-password            602
  1558.  
  1559.      Client operation block types
  1560.  
  1561.      client-list             700
  1562.      list-clients            701
  1563.      create-client           702
  1564.      delete-client           703
  1565.      reset-client            704
  1566.      force-client-reset      705
  1567.  
  1568.      Mailbox operation block types
  1569.  
  1570.      mailbox-list            800
  1571.      list-mailboxes          801
  1572.      create-mailbox          802
  1573.      delete-mailbox          803
  1574.      reset-mailbox           804
  1575.      expunge-mailbox         805
  1576.  
  1577.      Address operation block types
  1578.  
  1579.      address-list            900
  1580.      list-addresses          901
  1581.      create-address          902
  1582.      delete-address          903
  1583.  
  1584.  
  1585.  
  1586.  
  1587.  
  1588.  
  1589.  
  1590.  
  1591. Clark & Lambert                                                [Page 27]
  1592.  
  1593. RFC 993                                                    December 1986
  1594.  
  1595.  
  1596.      Bboard operation block types
  1597.  
  1598.      bboard-list             1000
  1599.      list-bboards            1001
  1600.      create-bboard           1002
  1601.      delete-bboard           1003
  1602.      subscribe-bboard        1004
  1603.      unsubscribe-bboard      1005
  1604.      set-bboard-first-unread 1006
  1605.      get-n-new-bboard-descriptors 1007
  1606.      list-all-bboards        1008
  1607.      bboard-name-list        1009
  1608.  
  1609.      Message operation block types
  1610.  
  1611.      descriptor-list         1100
  1612.      message                 1101
  1613.      get-descriptors         1102
  1614.      get-changed-descriptors 1103
  1615.      reset-changed-descriptors 1104
  1616.      get-message-text        1105
  1617.      print-message           1106
  1618.      copy-message            1107
  1619.      set-flag                1108
  1620.  
  1621.  
  1622.  
  1623.  
  1624.  
  1625.  
  1626.  
  1627.  
  1628.  
  1629.  
  1630.  
  1631.  
  1632.  
  1633.  
  1634.  
  1635.  
  1636.  
  1637.  
  1638.  
  1639.  
  1640.  
  1641.  
  1642.  
  1643.  
  1644.  
  1645.  
  1646.  
  1647.  
  1648.  
  1649.  
  1650. Clark & Lambert                                                [Page 28]
  1651.  
  1652.